Hi, as mentioned, will you do the standard library pendant? (provide api functions) else this isn't publicly usable unless users define @extern natives by themselves?

Updated this PR with the clean implementation (including handle validation, statement connection ownership tracking, auto-finalizing open statements when closing connections, and explicit interpreter error messages).

Also opened the WurstStdlib2 PR providing the native @extern bindings: wurstscript/WurstStdlib2#450

@codex review

@codex review

Follow-up: binding preservation + hardening pass

Pushed two commits addressing the sqlite_reset review comment and an adversarial review of the whole SQLite native surface.

4bceaef92 — preserve bindings across sqlite_reset

sqlite_reset no longer calls PreparedStatement.clearParameters(). It now mirrors sqlite3_reset() — resets execution state (closes the open ResultSet, clears the executed marker) while leaving bound parameters in place, so the bind once → step → reset → step again reuse pattern works. Added sqlite_clear_bindings (maps to sqlite3_clear_bindings()) for callers that explicitly want to drop bindings.

4ba78432e — hardening pass

• sqlite_exec ran only the first statement of a ;-separated script (JDBC/xerial silently drops the rest). Now splits and executes every statement, respecting string literals, quoted identifiers, and -- / /* */ comments.
• sqlite_open extension-loading vector: rejects smuggled URI query params (e.g. ?enable_load_extension=true) and explicitly disables extension loading, closing a load_extension() → dlopen native-code path reachable from a malicious compiletime dependency.
• sqlite_close connection leak: the connection is now always closed even if finalizing a statement throws (errors are aggregated), instead of leaking a connection already removed from the handle map.
• Rebind-without-reset silent no-op: (re)binding a parameter now invalidates prior execution state, so binding new values after a step re-executes on the next sqlite_step rather than being silently ignored.
• NULL vs empty/zero: added sqlite_column_is_null (via ResultSet.wasNull()) so callers can distinguish a real SQL NULL.
• Handle recycling: closeAllSqliteResources no longer resets the handle counter, keeping handles monotonic.
• Documented the 1-based bind / 0-based column index convention and the 32-bit truncation of sqlite_column_int (inherent to WurstScript's 32-bit int).
• Removed dead, cleanup-escaping fallback branches in RunTests.

Tests

• Compiletime tests for reset-preserves-bindings, multi-statement exec, rebind-without-reset re-execution, and NULL detection.
• Unit tests for the SQL statement splitter (semicolons inside string literals / quoted identifiers, comment stripping, empty-statement skipping).

All SQLite tests pass against sqlite-jdbc:3.46.1.3 on JDK 25.

@codex review

Codex Review: Something went wrong. Try again later by commenting “@codex review”.

Unknown error

@codex review

Codex Review: Something went wrong. Try again later by commenting “@codex review”.

Unknown error

Fixed: re-execute after sqlite_clear_bindings (8b9955b)

Confirmed and fixed. sqlite_clear_bindings called clearParameters() but — unlike the sqlite_bind_* methods — did not markStatementForReexecution. So after a statement had been stepped, clearing bindings left the executed marker set and any result set cached, and the next sqlite_step returned false without re-running, silently skipping execution with the now-NULL parameters unless the caller also called sqlite_reset.

Clearing bindings is a parameter mutation, so it now shares the exact re-execution semantics of (re)binding.

Regression tests (both verified to fail on the pre-fix code)

• sqliteClearBindingsAfterStepReexecutesWithoutReset — stale executed-marker path (INSERT): clear-then-step now re-runs and inserts the NULL row.
• sqliteClearBindingsAfterStepDiscardsOldResultSet — stale result-set path (SELECT): clear-then-step re-executes the query instead of continuing to walk the old cursor.

Swept the rest of the native surface for the same class of bug

The bug class is state-map inconsistency causing a silent no-op or stale read. I audited every state mutator against the sqliteExecutedStatements / sqliteResultSets invariants:

• Parameter/execution mutators — sqlite_bind_int/real/string ✅ mark for re-execution; sqlite_clear_bindings ✅ now does; sqlite_reset ✅ closes the result set + drops the marker inline. That's the complete set — no other method mutates parameters or execution state, so this was the only remaining instance.
• Handle allocation — connections and statements share one monotonic counter, so a statement handle can never alias a connection handle; finalized/closed handles are never reused. No aliasing loophole.
• sqlite_finalize / sqlite_close — both remove the handle from every map (statements, connections, result sets, executed set); close finalizes child statements and always closes the connection even if a child finalize throws. No orphaned marker/result-set entries.
• Reads past the last row / before a step — surface as loud InterpreterExceptions, not silent wrong results.

All 22 native unit tests pass, plus the full 354-test WurstStdlib2 suite (50 SQLite) compiled against this build.

@codex review

Codex Review: Didn't find any major issues. Chef's kiss.

Reviewed commit: 8b9955bd17